概述

通常，权限分为功能权限和内容权限。 功能权限： 菜单权限：设置菜单记录是否显示 （按角色分配菜单记录） 工具栏权限：设置工具栏图标是否显示（单独工具栏权限窗口） 界面权限：设置AD对象是否显示或者可桌面搜索（角色窗口权限设置） 流程权限：设置流程/报表是否可用（角色窗口权限设置） 工作流权限：设置工作流是否可用（单独工作流用户和权限设置窗口） 单据操作权限：与流程权限不同，每个单据表都包含”单据操作Doc_Action“字段，通过角色窗口单独设置操作权限记录。 内容权限： 组织访问权限：设置用户可以访问的组织（角色窗口权限设置） 界面内容权限：设置字段是否显示（角色层表级权限控制窗口） 字段内容权限：设置字段是否过滤，按权限匹配显示（） 报表内容权限：设置报表是否可用，报表内容是否按权限匹配（与流程一致，按角色分配权限） 提示内容权限：设置状态栏提示内容是否显示，按权限匹配（【默认无解】） 桌面内容权限：设置桌面显示的（单独桌面内容窗口设置权限） 仪表盘内容权限：设置仪表盘内容是否显示（绩效指标内容按角色分配） 权限管理包括：权限设计，权限申请，权限维护三块内容。 ==权限设计== 总体要求：面向业务，安全，可管理 通常复杂组织的权限管理架构是三层：公用角色--本地角色--岗位角色。 公用角色（ID设计）：没有组织访问，只设置功能访问，供本地角色继承（分配给本地角色使用）。 本地角色（实施经理设计）：按需求设置组织权限，再累加所分配的公用角色权限。 岗位角色（客户关键用户设计）：多个本地角色的合集。 多组织使用公用角色是必须的，可以大大减少角色的设置工作。不同组织角色只需设置本地角色继承公用角色即可。但对于小型企业或者组织，架构可以减为二层：本地角色--岗位角色。 与大型软件不同，id没有内置公用角色的权限设置，当有"主角色"这个选项概念，相当于共有角色，不能直接分配给用户但是能被其他角色所继承。公用角色具有面向业务性特征，比如采购业务：其公用角色有 采购-供应商管理，采购-申购，采购-商务，不同采购岗位灵活组合公用角色即可完成权限设定。 设计要求： 1. 保证公用角色的权限设置的正确性和完整性。 2. 岗位角色权限尽量细化，分配用户时灵活组合即可。 3. 保证只将岗位角色分配给用户，避免越层授权。 4. 保证权限继承的连续性，完善用户权限变更机制。 比如：用户权限变化，岗位角色组合是否满足，否，新建本地角色，再否，新建公用角色。 5. 角色编码，以利于统计和管理。 ==方案实例== 组织：组织架构影响用户和角色的权限设计。组织虚拟后，用户将工作于多个组织。 用户：默认属于一个行政组织，可以分配多个角色，可以分配多个组织访问。 角色：可以分组，支持下属角色，支持主角色（供其他角色继承权限，无法分配给用户）。 岗位：实际业务的权限实例，需要与角色权限一一对应。 设计粒度1：按实际岗位设计单独角色，无包含继承权限。 角色： 角色1：部门-经理（所有部门模块业务使用功能） 角色2：部门-全能（与经理相比，仅无审批权限） 角色3：岗位1 角色4：岗位2 角色5：部门-查询（必须，以分配其他部门用户使用） 用户： 部门经理=角色1 全能员工=角色2 岗位1=角色3 岗位2=角色4 优点：直观，继承关系简单，维护方便 缺点：权限设置重复，工作量大。 设计粒度2：按业务流程的具体权限动作设计，使用多个角色分配给用户得出目标权限 角色： 角色1：部门-岗位1 角色2：部门-岗位2 角色3：部门-查询 角色4：部门-审批 用户： 部门经理=角色1+2+3+4 全能员工=角色1+2+3 岗位1=角色1 岗位2=角色2 优点：权限设置量小。若岗位1的权限发生变化，只需修改二次，即可同步所有用户。方案1需要修改四次。 缺点：权限关系维护较复杂，如果细分作业权限，角色会更多。 ==权限实施== 流程：设计-测试-申请-实施-运维 步骤： 1. 确定业务模块 2. 分解业务功能，拟定公共角色，并设定为主角色 3. 根据组织架构，拟定各组织的本地角色，并包含相关公共角色 4. 拟定岗位角色，并包含相关本地角色。 ==权限申请== 三级流程：用户申请，部门审批，技术完成 五个功能：用户申请，部门审批，技术回执，权限报表，权限审计 通过ID系统内部的”工单请求Request“功能，可以简单完成前3个功能。权限报表需要自定义报表，在线审计需要自定义窗口。 ==权限审计== 审计目的：安全性，正确性 审计对象：管理员，超级用户，普通用户 审计内容：安全参数，权限范围，授权状态，时效性 ==权限规范== 1. 安全管理规范 2. 权限作业规范 3. 权限审计规范